For the past several years, different versions of IBM DOS, also known as PC DOS, have been marketed for use with data processing systems such as the IBM PC, XT, AT and PS/2 personal computers. The different versions of DOS and the different models of the personal computers are well known and documented. IBM DOS version 4.00 represents the current state of the art and was designed for use with and to support IBM PS/2 personal computers. When such personal computers are powered up, a power on self test (POST) routine or program is first executed, such program being stored in ROM. Upon the successful completion of such test, portions of DOS are read into the system memory from a hard disk or a floppy diskette and the system is booted up and initialized. The test, booting and initialization process can take many seconds. The present invention is directed to an improvement by which such process is significantly shortened in time. It is also common to start a personal computer by turning on not only a system unit but also a display, and the invention has an objective of accomplishing the start up process so that the system is available for use within the time required to warm up the display. That is, as soon as the system is turned on, the first screen becomes immediately visible on a display and gives the user the appearance of an "instant" load and initialization.
It is also known that the speed at which a ROM can be accessed is several orders of magnitude faster than the speed at which a hard disk or a floppy diskette can be accessed. The invention takes advantage of this known speed difference by storing portions of DOS in a ROM where such portions can be accessed at a speed much faster than the speed at which DOS could be accessed if such portions of DOS were stored on a hard disk or floppy diskette. However, the invention is more than simply substituting a ROM for a disk because of several problems. A first thought that might occur to many persons is that by storing DOS in a ROM, DOS can then be executed directly from the ROM. However, while certain portions of DOS, such as commands in the COMMAND.COM program, can be executed directly from ROM, other portions, such as IBMBIO.COM and IBMDOS.COM are altered and cannot be used in a read only device which precludes any alteration.
Another solution that might occur would be to create the ROM within the DOS address space, or within the first one megabyte of memory mapped space, and then load or copy DOS into a RAM (random access memory) within such address space to occupy and execute from the same space in RAM and operate in the same manner as DOS currently does. The disadvantage of such a solution is that two copies of DOS would then exist in such limited address space, one copy being the unalterable ROM DOS and the other copy being the alterable one that is stored in and executed from the RAM. Having two copies of essentially the same program in such a limited address space would not be efficient use of memory nor acceptable by many users.
A concept that has been only relatively recently introduced by IBM into the field of personal computers is that of an installable file system. An IFS was designed to allow alternate file systems to be used with DOS and OS/2. Previously, only the well known file allocation table (FAT) file system was supported. An IFS was a feature of DOS version 4.00 which was used for a network file system to interconnect a personal computer and a network server. An IFS was also included in OS/2 version 1.2 and used for the high performance file system (HPFS) designed for high performance, large capacity disk drives.
In the course of arriving at the solution to the problem of how DOS could be loaded from a ROM, we made a double observation. First, is there a way to make ROM look like a hard disk file? If so, then DOS could be used in its previous form without having to make many changes. Second, we then recognized that the IFS interface and concept allows a ROM to be used as a disk image. Such solution was advantageous in several ways. Since few changes need be made to DOS, the invention could be developed rapidly. Fewer changes makes the resultant program more reliable and of higher quality.
The foregoing describes in general terms the prior art being improved upon, and such prior art is also believed to be the most pertinent or relevant to the invention. However, certain patents are also known which describe inventions using programs stored in ROM to initialize computers. U.S. Pat. No. 4,757,533--Allen et al for SECURITY SYSTEM FOR MICROCOMPUTERS, discloses a personal computer security system which is initialized using the prior art process. When DOS processes the AUTOEXEC.BAT file, code is accessed in a ROM to set up the security system. Obviously, such system does not load an operating system from ROM but operates in accordance with the prior art being improved upon by the present invention.
U.S. Pat. No. 4,688,172- Wright, for INITIALIZATION APPARATUS FOR A DATA PROCESSING SYSTEM WITH A PLURALITY OF INPUT/OUTPUT AND STORAGE CONTROLLER CONNECTED TO A COMMON BUS, discloses a data processing system which is initialized from a ROM in a manner to solve a problem different from that solved by the present invention. The invention is directed to initializing a computer using a DOS stored in ROM. The patent does not appear to utilize DOS nor teach how to initialize such a system. The patent is directed to solving the problem of how to initialize a data processing system having a plurality of programmable controllers which during normal operation compare addresses with stored identifiers to see which controller is being accessed. When the system is turned on, such identifiers are stored on disk and are not yet loaded, and that creates the problem. The solution to such problem is to disable the use of identifiers during initialization and access only a master controller with normal addresses excluding an identifier. Such solution differs from and does not teach the present invention.
U.S. Pat. No. 4,462,086--Kurakake, for LOADING SYSTEM IN NUMERICAL CONTROLLER, discloses a system having a main processor for executing programs in a RAM. The system also has a subprocessor including a ROM storing a loading program and a control program. When power is turned on, the main processor transfers the loading program from the subprocessor ROM into RAM or executes it directly from the ROM to load the control program from the ROM into RAM. The present invention does not employ a subprocessor having a ROM therein. Such patent does not teach how to initialize a DOS based system from ROM and overcome the problems associated therewith.
U.S. Pat. No. 4,654,783--Veres et al, for UNIQUE PROCESS FOR LOADING A MICROCODE CONTROL STORE IN A DATA PROCESSING SYSTEM, discloses a non-DOS based system having a microcode control store. The purpose of the described invention is to load one of a plurality of different microcode instruction sets stored on different floppy discs. When power is turned on, a kernel program stored in a ROM is loaded into the microcode control store. The kernel first tests the system and then accesses an I/O device to load a loading program from the I/O device which loading program then loads the desired microcode instruction set from the I/O device into the control store. The processor then, acting under the control of the microcode, loads an operating system to place the system in use. In the present invention, the loading program and the operating system are not stored in nor loaded from an I/O device but from ROM.